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Abstract 



The paper presents three self-stabihzing protocols for basic fair and reh- 
able hnk communication primitives. We assume a hnk-register communica- 
tion model under read/write atomicity, where every process can read from 
but cannot write into its neighbours' registers. The first primitive guaran- 
« I tees that any process writes a new value in its register(s) only after all its 

C^ ■ neighbours have read the previous value, whatever the initial scheduling of 

processes' actions. The second primitive implements a "weak rendezvous" 
communication mechanism by using an alternating bit protocol: whenever a 
process consecutively writes n values (possibly the same ones) in a register, 
J^ . each neighbour is guaranteed to read each value from the register at least 

^r^ I once. On the basis of the previous protocol, the third primitive implements a 

^D ■ "quasi rendezvous" : in words, this primitive ensures furthermore that there 

exists exactly one reading between two writing operations 
J;^^ I All protocols are self-stabilizing and run in asynchronous arbitrary net- 

f— ^ ' works. The goal of the paper is in handling each primitive by a separate pro- 

cedure, which can be used as a "black box" in more involved self-stabilizing 
protocols. 
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1 Introduction 

A self-stabilizing system which is started from an arbitrary initial configuration, 
regains its consistency and demonstrates legal behaviour by itself, without any 
outside intervention. Consequently, a self- stabilizing system needs not be initiated 
to any configuration, and can recover from transient faults. More precisely, it can 
recover from memory corruptions and copes with processors or channels crashes 
and recoverings (i.e., dynamic networks). 

1.1 The Communication primitives 

In the paper, we present fair and reliable self-stabilizing communication primitives 
in the link-register model. The communication between two neighbours (^4 and 
B) is carried out by the use of two sets of communication registers called registers: 
Tab and tba- Process A can write in the registers of r^s and each process A and 
B can read from the registers of r^s.The registers support read and write atomic 
operations. For example, let S = {a, b, c, e} be an alphabet and w = aaabbbbcc = 
a^b'^c^ a sequence of valuewritten by A into r^s. The communication primitives in 
their very first basic form do not ensure more than e.g.: a*b*c* is eventually read 
by 5. 

The first presented primitive guarantees that any process A writes a new value 
in its register(s) WriteAB only after its neighbour B has read the previous value. 
Notice that when A writes n times the same value consecutively in the register 
Write AS ^ the primitive ensures that B eventually copies this value at least once. 
For example, given S and w as above, the first primitive only guarantees that e.g., 
aa*bb*cc* is eventually read by each neighbour: each symbol in w, (a, b and c) is 
read at least once, whatever the number of occurrences. This primitive simulates 
self-stabilizing reliable message-passing communication in the link-register asyn- 
chronous model. It guarantees that a message, that is the value of the register 
Write, is eventually received: the value is eventually known from the neighbours' 
process. 

The rendezvous mechanism (as defined in [TBj) synchronizes communications, 
i.e., the write and read operations are performed in and from the same register. 
When Process A writes a value in its register WritcAB, it cannot perform any other 
action until process B has completed a read operation from the register WriteAB- 

The second communication primitive is a self-stabilizing "weak rendezvous". 
After performing a write operation in its register WriteAB, the process A cannot 
perform but some specific actions, as long as process B has not completed a read 
operation from WriteAB- Therefore, if A consecutively writes n values (possibly 
the same ones) in the register WriteAB, the primitive guarantees that B eventually 



copies each value at least once. If A writes n times the same value in Write ab, 
the value will be read at least n times. As an example, given S and w as above, 
the second primitive at least guarantees that e.g., a^a*b'^h*c^c* is eventually read 
by each neighbour: each symbol in w (a, h and c) is read at least the number of 
times the symbol occurs in w (but any symbol may be read strictly more than its 
number of occurrences). 

The third self-stabilizing communication primitive performs a quasi synchro- 
nization. It is a "quasi rendezvous" mechanism and requires that between two 
write operations performed by the process A in Write ab, the process B cannot 
perform but one and only one read operation from Write ab- Therefore, if A writes 
n consecutive times the same value (possibly the same one in each row) in the reg- 
ister Write AB, the primitive guarantees that B will copie each of the n values 
exactly one time, once the system is stabilized. For example, given again E and 
w as above, the third primitive does ensures that exactly a^b'^c^ is eventually read 
by each neighbour: each symbol in w (a, b and c) is read exactly the number of 
times it occurs in w. 

Each such primitive may prove useful as a communication "black box" in de- 
signing more involved distributed self- stabilizing protocols. 

1.2 Related Works and Results 

A deterministic self-stabilizing "balance-unbalance" mechanism on two processes 
systems under read/write atomicity is presented in [12] and in [13]. The two 
processes are not executing the same code. The one executes the balance code: 
when both processes have the same color, it changes color. The other executes the 
unbalance code: when both processes have not the same color, it changes color. 
In [12], this mechanism is used to guarantee that each process has a mutual ex- 
clusion access to a critical section, and in ^13j , it is used to ensure synchronization 
of the processes. In both cases, this mechanism provides strong synchronization: 
between two "actions" of a process, the other process cannot perform but only one 
"action". In [121 [13], the two processes protocol is used to design a mutual exclu- 
sion algorithm (global synchronization) on tree networks. As claimed in [T^ [T3] , 
the balance-unbalance mechanism cannot be extended to any network topology, 
since there exist no deterministic self-stabilizing synchronization protocols in uni- 
form arbitrary networks. On the other hand, a self-stabilizing synchronization on 
unidirectional rings is provided in [TU] through the deterministic token circulation 
mechanism: between two actions of a process its neighbours cannot perform but 
only one action. 

Any self-stabilizing reset protocol [3 El |8] can be combined with the protocol 
in [6] to design a self-stabilizing synchronizer. General self-stabilizing synchroniz- 



ers are presented e.g. in [9l [TJ [19]. Global self- stabilizing synchronizers for tree 
networks are also proposed in p!3l |3l |Tl] . A self- stabilizing local synchronizer, that 
synchronizes each node in a tree network with its neighbours is presented in [18]. 
In the recent literature, several communication problems in the message-passing 
model have been addressed. A self-stabilizing communication protocol for two-way 
handshake is presented in [T5|, and a self-stabilizing version of the alternating-bit 
protocol is given in [1] . In [1] , Anagnostou and Hadzilacos present a self-stabilizing 
data link protocol under the read/write atomicity model such that, between two 
write operations in the register, only one read operationfrom that register is per- 
formed. However, no proof of the protocol is given in their paper. By contrast, 
our last two primitives use the alternating-bit mechanism, and since the two bits 
values must begin with the same value 0, our algorithm in section [7] is twice as 
fast as in |1]. 

Section |2] describes our model with the basic assumptions. In Section [3], we 
present the general principle of our solution for a two processes system. The 
generalization to n processes in arbitrary networks yields the Read Checking self- 
stabilizing protocol, which is presented in Section HJ Section \5\ is devoted to the 
proof of liveness and correctness of the Read Checking protocol. Section [6] presents 
the weak rendezvous protocol and Section [7] describes our quasi rendezvous proto- 
col. Finally, the paper ends with few concluding remarks. 

2 Model and Requirements 

Although distinct from the one described in [12] , our model relies on close require- 
ments and assumptions, especially in terms of communication (e.g., link registers, 
read/write atomicity, etc.). A distributed system consists of n processes denoted 
A, B, etc. Each process resides on a node of the system's communication graph 
(or network ). Two processes which reside on two adjacent nodes of the network 
are called neighbours. We model distributed self-stabilizing systems as a set of 
(possibly infinite) state machines called processes. Each process can only com- 
municate with the subset of processes consisting of its neighbours. We assume a 
link-register communication model under read/write atomicity [T2|. Each link be- 
tween any two neighbours A and B is composed of two pairs of register^!!, denoted 
(W rite AB, Read ab) and {WritesA, ReadBA), and belonging to A and B, respec- 
tively. Process A can read from the two registers of B, WritesA and ReadBA, but 
cannot write into them. Similarly, process A cannot write but in its own registers, 
WriteAB and ReadAB, to communicate with B. 



^In our model, the registers are physical (hardware) devices. Reading from or writing in one 
register is an atomic action according to the design of the microprocessor. 



A configuration of the system is the vector of states of all processes. The state 
of a process is the value of its internal variables and the contents of its registers. 

2.1 Schedulers, Demons and Computation 

An atomic step is the "largest" step which is guaranteed to be executed uninter- 
ruptedly. A process uses read/write atomicity if each atomic step contains either 
a single read operation or a single write operation but not both. The system 
behaviour is modelled by the interleaving model in which processes are activated 
by a scheduler. The scheduler is regarded as a fair adversary: in a self-stabilizing 
system, all possible fair executions are required to converge to a correct behaviour. 
A fair scheduler shall eventually activate any process which may continuously per- 
form an action. A common scheduler activates either processes one by one (central 
demon) or subsets of processes (distributed demon). Under read/write atomicity, 
both central and distributed schedulers/demons are "equivalent", in the sense that 
any execution performed under a distributed scheduler may be simulated by a cen- 
tral one. A process which can perform an atomic step into a configuration c, is 
said to be enabled at c. During a computation step, one or more processes execute 
an atomic step. A computation of a protocol P is a sequence of configurations 
Ci,C2, . . . such that, for i = 1,2, . . ., the configuration Cj+i is reached from Cj by 
one computation step. A computation is said to be maximal either if the sequence 
is infinite, or if it is finite and no process is enabled in the final configuration. A 
problem is a predicate defined on computations. 

2.2 Self-Stabilization 

The protocol V is self- stabilizing for the problem 11 if and only if there exists a 
predicate C defined on configurations such that: 

• all computations reach a configuration that satisfies C (convergence); 

• all computations, from C, satisfy problem 11 (correctness). 

Notice that the maximal computations of a self-stabilizing protocol may be 
finite; in that case the algorithm is said to be silent [H]. Most self-stabilizing al- 
gorithms which build spanning tree or elect a leader are silent [17]. Self-stabilizing 
protocols offers full and automatic protection against all transient process failures, 
no matter how much the data have been corrupted: e.g., all registers values may 
be fully corrupted. 

So, whatever the registers values, our protocols secure the transfer of informa- 
tion between any two pair of neighbours after a "certain delay time" . 



3 Principle of the Solution 

Let a two processes system, consisting in two neighbouring processes A and B 
equipped with their two pairs of registers (see Section [2]). The principle of the 
solution for A relies on the following basic idea. Under read/write atomicity, A 
systematically keeps reading the value from WritesA and copies out this value 
in ReadAB (i-e., A reads the message sent by B and copies out the message in 
ReadAB to inform B that its message is received). Besides, A systematically keeps 
reading the value from Reads a and compares it to the value of Write ab- When 
both values are equal, A finds out that B somehow read that value (i.e., the 
information has been transmitted). So it can stop reading and can write again in 
WriteAB- 

while true do 

A writes in WriteAB 
repeat 

A reads from WritesA ', 

A writes out the value of WritesA into ReadAB ', 
A reads from ReadsA 
until ReadsA = WriteAB 
endwhile 

Fig. 1. The basic 2-processes protocol for A. 



After A has written a new value in WriteAB, A becomes "weakly locked" until 
B receives the message {Reads a = WriteAB)- When A is inside the repeat 
loop, it can only perform some actions, for instance, A cannot write in its register 
WriteAB- 

In a self-stabilizing setting, A may then proceed with the execution of its own 
code, since the protocol makes it sure that B did read the value from WriteAB 
(at least, it results from the protocol that A knows for sure that the values in 
Reads A and WriteAB are identical). The corresponding code sequence for B is of 
course fully symmetrical to the basic protocol for A: the roles of A and B (i.e. the 
registers' names) have simply to be inverted within the above protocol in Fig. 1. 
Thus, a two-way communication is established between A and B. 

4 The Protocol in Arbitrary Networks 

The generalization of the above protocol to a system of n > 2 processes constituting 
an arbitrary network is now easy. We still assume each pair of neighbouring 



processes in the network to be equipped with its two pairs of registers on their 
common hnk. In order to simphfy the use of variables, we call "message" the 
"information" exchanged between neighbours during the execution of the protocol. 
A protocol which stabilizes on a single link may not generalize to a protocol 
which stabilizes on all links of a (finite) network, e.g. by having each process exe- 
cute the "link-protocol" in a round robin manner on each individual link adjacent 
to it. Taking the n-processes system pair by pair may cause a deadlock: for all 
i G {0, ... ,n — 1}, Ai may be waiting for A+i to read from WritcAiAi+i, with 
An = Ao. 

4.1 Notation 



Write register for A: ReadABt is the register in which A writes the value of 
the last message read by A and sent by Bi. 

Read register for A: WritcBiA is the register in which Bi writes the message 
to be transmitted to A, and Reads^A is the register in which Bi writes the value 
of the last message read by B^ and sent by A. 

Write and read register for A: WritcABi is the register in which A writes 
the value of the message which is to be sent to its ith neighbour Bi. 

Function geti for A: geti takes no argument and returns the next message 
to be sent to the zth neighbour of A {geti is a helper function added to A). 

4.2 The Read Checking Protocol 

On the same assumptions for the model (read/write atomicity) and for the sched- 
uler's actions (rules of activations of processes and fairness) as given in Section [21 
the specification of the self-stabilizing Read Checking protocol in arbitrary net- 
works for a process A, with neighbours BiS {1 <i < Na), is as follows. 

constant Na '■ the number of neighbours of A ; 

var Si : message to be sent to the ith neighbour of A ; 

Tj : message sent from the zth neighbour of A ; 

vali : value of the last message sent from A and read by the zth 
neighbour of A ; 

while true do 

for z = 1 to A^^ do 

write{WriteABi, geti) ] 
endfor 
repeat 



for z = 1 to Na do 

ri <- read{WriteB,A) ] 
write{ReadABa^i) ; 
vali ^ read{ReadBiA) 
Si ^ read{WriteAB,) ] 
endfor 
until ( Vz G [1, Na] vaU = Si ] 
endwhile 



Fig. 2. The Read Checking protocol for A. 



5 Proof of the Read Checking Protocol 

5.1 Proof of Liveness 

Lemma 5.1 Whatever the execution, every process performs an infinite number 
of actions. 

Proof. Read/write atomicity ensure tliat eacli process is always enabled. 

Therefore, every execution is infinite (every configuration is deadlock-free), and 
in each configuration that is reached every process can perform an action (fair 
scheduler). The scheduling of processes' actions is fair: if a process can always 
execute an action, then the process finally performs an action. Thus, by fairness, 
every process is performing an infinite number of actions, whatever the execution. 
D 

Lemma 5.2 Let A be a process with its program counter in the repeat loop and 
let B be a neighbour of A. Whatever the current configuration and the execution, 
the processes system executing the protocol either eventually reaches a configuration 
in which B allows A to write, or A exits the repeat loop. 

Proof. Suppose B never allows A to write and A never exits the repeat loop. 
Then A never changes the value in its register Write ab- Under these conditions, 
updating its register Reads a is a writing permission given to A by -B (since between 
the reading of the value from the register WritcAB and the writing of that value 
in Reads A, the register Write ab does not change value). 

Whatever the current configuration and the execution, if the program counter 
of B is not within the repeat loop, it takes B less than A^^ actions to enter the 
repeat loop. Once B enters the loop, after ANb actions, it updates all its Read 
registers, and thus allows A to write. 



Whatever the current configuration and the execution, if the program counter 
of B is within the repeat loop, it takes B at least ANb actions either to exit the 
loop, or to update its register ReadAB- 

Whatever the execution, B performs an infinite number of actions (by 
Lemma I5.2p and eventually, either B allows A to write, or A exits the repeat 
loop. D 

Definition 5.1 Let A and B he two neighbouring processes. A is said to allow B 
to write iff Reads a = WriteAB ■ Let A be a process and let Na denote the number 
of neighbours of A (Na is the degree of A in the network). 

Definition 5.2 Let A and B be two neighbouring processes. The update of the 
register ReadAB is the sequence of the two following actions performed by B: 
Ti -(— reaidiWriteAB) ', v/rite{ReadBA,ri). 

A wrong writing is a write action in the register ReadsA which is not performed 
within the context of an update. (The correct writing into the register ReadsA is 
a write action executed within the context of an update.) 

Lemma 5.3 After executing its first action, no process can perform a wrong writ- 
ing. 

Proof. Process A can perform at most one wrong writing, and it may only 

happen when initially its program counter is set up after reading from the Write 
register and before writing in the Read register. Once this write action is executed, 
each write action of A in a Read register is performed within the context of an 
update. D 

Lemma 5.4 Let A and B be two neighbouring processes. After B executes its first 
action, if B allows A to write, then only the writing of A in its register WritCAB 
may be able to cancel that permission. 

Proof. Nothing but writing into the register ReadsA or into the register 

WriteAB can cancel the writing permission. After B executes its first action, from 
Lemma E3] there is no wrong writing anymore. Hence, any writing into the register 
ReadBA is executed within the context of a register's update. This update is such 
that the permission remains given to A, unless A writes into its register ReadBA 
during the updating process or after the last update. D 

Theorem 5.1 Let A be a process. Whatever the execution, the system of processes 
which performs the protocol reaches a configuration in which A is not within the 
repeat loop anymore. 



Proof. Suppose A remains within the repeat loop forever; then A never writes 
into its Write registers. Every ANa actions, A is checking out the loop exiting 
condition. Whatever the execution, process A performs an infinite number of 
actions. Hence, A checks out the repeat loop exiting condition an infinite number 
of times. In particular, A tests the exit condition an infinite number of times after 
all its neighbours have already executed an action. 

If at some test all neighbours of A allow its writing, then, at the next test, 
all its neighbours keep on giving A permission to write (by Lemma 15. 4p . In the 
meanwhile, A has updated its variables r^ and Sj, and when the test happens, the 
loop exiting condition is satisfied: A exits the loop. 

Process A stays within the loop infinitely long in the case when, at each test, 
at least one neighbour does not allow its writing. Once a neighbour has allowed 
A to write, this neighbour cannot withdraw permission from A. Therefore, there 
exists at least one neighbour of A which never allows A to write. Now from 
Lemma [5. 2[ this is impossible, and the theorem follows. Therefore, the protocol is 
deadlock-free. D 

Corollary 5.1 Let A be a process. Whatever the execution, A writes an infinite 
number of times into all its Write registers. 

Proof. If A is out of the loop, then it takes A less than Na actions to enter 
the loop. When it is within the repeat loop, then by Theorem 15. ![ A cannot 
stay infinitely long. A^^ actions after exiting the loop, A writes into all its Write 
registers and reenters the repeat loop. D 

5.2 Correctness Proof of the Read Checking Protocol 

Theorem 5.2 Let A and B be two neighbouring processes. After B executes its 
first action and after any writing in the register WritcAB, A can write in the 
register WritcAB only if B allows it, i.e. ReadBA = WritCAB (see Definition \5.1\) . 

Proof. Process B is the zth neighbour of A. Between each of its two writings, 
A enters the repeat loop and exits the loop. Once A is within the loop, the 
register WritcAB does not change value. The repeat loop's code is such that 
when the loop is exited, the value of the local variable Si of A and the value of 
the register WritcAB are equal. In the loop, the local variable r^ of A takes the 
value of the register ReadAB- The value of the register ReadBA may change after 
this assignment and before the loop is exited. Thus, when the loop is exited two 
distinct cases have to be considered: 

• No update of the register ReadBA happens between the reading from that 
register and the loop exit. Then, Sj = WritcAB = vali = ReadsA, and B allows 
the writing of A. 

10 



• Writings into the register ReadsA happen between the reading from that 
register and the loop exit. However, the latter writings are performed within 
the context of updating. Hence, each time the value has changed, we have that 
Reads A = Write ab and, by Lemma [531 the equality holds while A does not rewrite 
into the register Write ab- D 

After the writing of a value in the register Write ab, the first primitive guar- 
antees that A will only write in the register Write ab if B allows it. In the case 
when the value is new, B must perform the action resid{W rite ab) to allow the 
writing. 

Summing up of the Results 

1. The protocol is live: every process is updating all its Write registers an 
infinite number of times. 

2. The protocol is correct: no process can write distinct values twice in a 
row in its Write register without any previous reading from that register. 

6 The Weak Rendezvous Protocol 

In this section, we present a self-stabilizing weak rendezvous communication prim- 
itive. 

Recall that The rendezvous mechanism (as defined in [16]) synchronizes com- 
munication in the link-register asynchronous model of distributed system: each 
write or read operation is performed in and from the same register. When Pro- 
cess A writes a value in its register WriteAs, it cannot perform any other action 
until process B has completed a read operation from the register WritcAs- 

The weak rendezvous mechanism only requires that between two write opera- 
tions performed by a process A in Write ab, process B performs at least one read 
operation from Write ab- Therefore, if A writes a value n consecutive times (even 
the same ones in each row) in the register Write ab, the primitive guarantees that 
B copies each of the n values at least one time, once the system is stabilized. 

The weak rendezvous mechanism is based upon the alternating bit technique. 
After writing in its register Write ab, process A changes the value of the bit-register 
C antral AB- A can write again in the register WriteAB only after B has copied 
the new value of C antral ab into the register CheckCantralBA- And B copies the 
value only after reading in the register WritcAs- 

The liveness proof of the weak rendezvous protocol is similar to the proof of 
the read checking protocol. The following Theorem 16.11 proves the correctness of 
the weak rendezvous protocol. 

11 



Theorem 6.1 Let A and B he two neighbouring processes. After B executes its 
first action and after the xth (> 2) writing in the register WritcAB, B reads the 
value from WritcAB before the next writing in WritcAB- 



Proof. As shown in Theorem I5.2[ we can establish that before the xth writing 
in the register Write ab, ControlAB = CheckControlBA- After the writing in the 
register Write ab, A changes the value in ControlAB and enters the repeat loop 
{ControlAB 7^ CheckControlBA)- A stays within the loop as long as B does not 
copy the value of ControlAB into the register CheckControlBA- Finally, B copies 
the value only after reading in the register WritcAB- D 

The weak rendezvous protocol maintains a weak scheduling of the communi- 
cation between processes in the following sense. We call a weak scheduling of the 
communication between process A and all its Na neighbours the property that 
A can write twice into its registers WritcABi, only whenever all the i3j's did read 
from the register Write ab, in the meantime (1 < z < Na)- 

constant A'^ : the number of neighbours of A ; 

var Tj : message sent from the ith neighbour of A ; 

bi : alternate bit sent from the ith neighbour of A ; 

Ci : alternate bit sent from A to the ith neighbour of A ; 

li : value of the last alternate bit sent from A and read by the ith 

neighbour of A; 
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while true do 

for i = 1 to Na do 

write{W r ite AB,, geti) ; 
Ci ^ re8id{C ontrolABi) ; 
write{ControlABi, (cj + 1) mod 2) ; 
endfor 
repeat 

for z = 1 to A^^ do 

Vi ^ resid{WriteB,A) ; 
bi i— read (Contro/fiiA) '■, 
write{C heckControlABi,bi) ; 
Ci ^ read{C ontrolABi) ', 
U ^ reaidiCheckControlBiA) ; 
endfor 
until ( Vz G [1,Na] c, = k) 
endwhile 

Fig. 3. The weak rendezvous protocol for A. 



7 The Quasi Rendezvous Protocol 

In this section, we present a self- stabilizing quasi rendezvous communication prim- 
itive. A close idea may be found in |1], where the authors also present a self- 
stabilizing data link protocol under read/write atomicity such that, between two 
write operations in the register, there is only one read operation from that register. 
(See our remarks in section ITT^ ) 

The quasi rendezvous mechanism requires that between two write operations 
performed by the process A in WriteAB, the process B cannot perform but one 
and only one read operation from WritcAB- Therefore, if A writes n consecutive 
times the same value (possibly the same one in each row) in the register Write ab, 
the primitive guarantees that B will copie each of the n values exactly one time, 
once the system is stabilized. 

The quasi rendezvous mechanism is based upon the alternating bit technique. 
After reading from the register WritcAB, the process B copies the value of the bit- 
register Control AB into CheckControlBA- Now, B can read again from the register 
Write AB only after A has changed the value of ControlAB- And A changes that 
value only after writing in the register WriteAB- 
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constant Na '■ the number of neighbours of A ; 

var Tj : message sent from the ith neighbour of A ; 

bi : alternate bit sent from the ith neighbour of A ; 

Ci : alternate bit sent from A to the ith neighbour of A ; 

/j : value of the last alternate bit sent from A and read by the ith 
neighbour of A; 

di : value of the last alternate bit sent from the ith neighbour of A 
and read by A 

while true do 

for i = 1 to A'^ do 

writeiWriteAB,, geti) ; 

Ci ^ read{ControlABi) ', 

write{C ontrolABi, (q + 1) mod 2) ; 
endfor 
repeat 

for i = 1 to Na do 

bi ^ read{ControlBiA) ', 

di ^ read{CheckC ontrolABi) ', 

if bi 7^ di then 

Tj ^ re8id{WriteB,A) ; 
write{C heckControlABi,bi) ; 
endif 

Ci •(— read{C ontrolABi) ', 
li -^ resid{CheckControlBiA) ', 
endfor 
until ( Vi G [1,Na] Ci = k ) 
endwhile 

Fig. 4-. The quasi rendezvous protocol for A. 

The liveness proof of the quasi rendezvous protocol is similar to the proof of 
the read checking protocol. 

Definition 7.1 Let A and B be two neighbouring processes. B is said to allow A 
to write iff CheckControlBA = ControlAB- 

Definition 7.2 Let A and B be two neighbouring processes. The full reading of 
register WriteAB is completed by the sequence of the four following actions per- 
formed by B: 

b ^ resid{ControlBA) / d ^ resid{C heckControlAB) ; if b ^ d then {r ■(— 
re8id{WriteBA) ; "write{C heckControlAB, b) ;}. 

14 



Definition 7.3 Let A and B he two neighbouring processes. The full writing of 
register WriteAB is completed the sequence of the three following actions performed 
by A: 
y<rv\te{WriteAB^9e-t) ; c -(— read(Contro/AB) ; write(Contro/yiB, (c+ 1) mod 2) ; 

Lemma 7.1 Let Abe a process with its program counter in the repeat loop and let 
B be a neighbour of A. Whatever the current configuration and the execution, the 
system of processes executing the protocol either eventually reaches a configuration 
in which B allows A to write, or A exits the repeat loop. 

Lemma 7.2 After executing its first three actions, no process can perform an 
incomplete reading or writing. 

Lemma 7.3 Let A and B be two neighbouring processes. After B and A execute 
their first three actions, if B allows A to write, then only the complete writing of 
A in its register WritcAB fnO'y be able to cancel that permission. 

Proof. The proof of the three above lemmas (17. ![ 17.21 and l7.3p is similar to the 
proof of Lemma 15. 2[ Lemma 15.31 and Lemma 15. 4[ respectively. D 

Theorem 7.1 Let A be a process. Whatever the execution, the system of processes 
which performs the protocol reaches a configuration in which A is not within the 
repeat loop anymore. 

Sketchproof. The proof is by contradiction and it is similar to the proof of 
theorem 15.11 D 

Corollary 7.1 Let A be a process. Whatever the execution, A writes an infinite 
number of times into all its Write registers. 

The following Theorems 17.21 and 17.31 prove the correctness of the quasi rendezvous 
protocol. 

Theorem 7.2 Let A and B be two neighbouring processes. After A and B execute 
their first three actions and after the xth (> 2) writing in the register Write ab, B 
reads the value from WritcAB before the next writing in WritcAB can take place. 

Proof. We can establish that before the xth writing in the register WriteAB, 
ControlAB = CheckControlBA- After writing into the register WriteAB-, A 
changes the value in ControlAB and enters the repeat loop {ControlAB 7^ 
CheckControlBA)- ^ stays within the loop as long as B does not copy the value 
of ControlAB into the register CheckControlBA- Finally, B copies the value only 
after reading from the register WriteAB- D 
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Theorem 7.3 Let A and B be two neighbouring processes. After A and B execute 
their first three actions and after B reads from WritcAB, A performs a complete 
writing in WritCAB before the next reading from WritCAB- 

Proof. Before the reading from WritcAB, ControlAB 7^ CheckControlBA- After 
the reading from the register Write ab, B changes the value in CheckControlBA 
Now, B does not change the value in CheckControlBA {B does not read from the 
register WritcAB) as long as A does not change the value in ControlAB- After the 
first three actions of A, changing the value in ControlAB is made after A's writing 
in WritcAB- D 

The quasi rendezvous protocol maintains a scheduling of the communications 
between processes in the following sense. We call a scheduling of communications 
between process A and all its Na neighbours the property that A can write twice 
into its registers WritcAB^, only whenever each of the Sj's performed one unique 
reading from the register WritcABi in the meantime {1 < i < Na)- 

8 Concluding Remarks 

The paper presents three very basic general protocols for the design of fair and 
reliable self-stabilizing communication primitives. Both protocols work in arbi- 
trary networks and also ensure minimal scheduling properties, whatever the initial 
configuration of the system of processes and the activations by the scheduler. In 
particular, the last protocol entails the mechanism of a "quasi rendezvous" , which 
proves useful in more involved self-stabilizing protocols. 

Each primitive can actually be used as a "black box" by a separate protocol, 
handling the procedures in more involved self-stabilizing algorithms. Thus, the 
protocols may be modified according to the designer's will and needs: e.g., in spe- 
cific topologies of networks a weak scheduling of communications may impose fewer 
neighbours to read from the registers. For example, with only one neighbour, a 
point to point self-stabilizing quasi rendezvous mechanism may also be completed. 
Along the same lines, the protocols also simulate reliable self-stabilizing message- 
passing in asynchronous distributed systems. 

Although the paper does not concern itself with complexity measures, it is 
worth mentioning that when time is measured by some appropriately defined round 
complexity, the stabilization time of the read checking protocol is 0(1). 
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